定义1：

Definition 1:

属性图 G是六元组（五,埃, ρ , λ , σ, δ） ， 在哪里：

A Property Graph G is a six-tuple (V,E,ρ,λ,σ,δ) , where:

• 五⊂ V I D 是一组有限的节点；

• V⊂VID is a finite set of nodes;

• 埃⊂ E I D 是一组有限的边；

• E⊂EID is a finite set of edges;

• ρ : E→五×五 是一个将E中的每条边与V中的一对节点相关联的函数；

• ρ:E→V×V is a function that associates each edge in E with a pair of nodes, both in V;

• λ :电压∪伊→2大号 是一个将每个节点和边与一组标签（可能是空的）相关联的函数；

• λ:V∪E→2L is a function that associates each node and edge with a set (which may be empty) of labels;

• σ: (五∪伊) × P r o p s ↦2瓦尔​​​ 是一个用属性名称和属性值连接节点和边的部分函数；

• σ:(V∪E)×Props↦2Vals is a partial function that connects nodes and edges with property names and property values;

• δ：E→ { → , ← , ↔ } 是一个为每条边分配方向的函数。

• δ:E→{→,←,↔} is a function that assigns a direction to each edge.

定义 2（模式）：

Definition 2 (Schemas):

让G = （V,埃, ρ , λ , σ, δ） 是一个属性图。节点的架构 n∈V​​ 是属性名称的集合sch (n)={p∣(n,p)∈ dom (σ）} . 类似地，边的模式 e∈E​​ 是属性名称的集合sch (e)={p∣(e,p)∈ dom (σ）} .我们表示为学校节点（七） G中所有不同节点模式的集合（即学校节点( G ) = { sch ( n ) ∣ n ∈ V} ）以及学校边缘（七） G中所有不同边模式的集合（即学校边缘( G ) = { sch ( e ) ∣ e ∈ E} ）。

Let G=(V,E,ρ,λ,σ,δ) be a property graph. The schema of a node n∈V is the set of property names sch(n)={p∣(n,p)∈dom(σ)} . Similarly, the schema of an edge e∈E is the set of property names sch(e)={p∣(e,p)∈dom(σ)} . We denote by schnode(G) the set of all different node schemas in G (i.e., schnode(G)={sch(n)∣n∈V} ); and by schedge(G) the set of all different edge schemas in G (i.e., schedge(G)={sch(e)∣e∈E} ).

GraphML

A. GraphML

图形标记语言 (GraphML) [13]是一种将图形存储为 XML 的文件格式。GraphML 有两个部分。第一部分是边和节点的属性名称和数据类型的定义。在定义节点的属性之前，需要定义一个特殊的属性标签V可用于存储节点标签。然后，定义所有节点属性名称。类似地，属性标签E可以为所有边属性名称后面的边标签定义。在第二部分中，每个节点都定义在<节点>标签包含其标签和属性值；然后每条边在<边缘>标签。属性定义为<数据>标签在 key 属性中指定名称。多个<数据>具有相同标签钥匙为了支持多值属性，节点或边不允许有值。在图 2中，我们展示了一个 GraphML 文件，该文件序列化了图 1中显示的属性图的数据，其中多标签和多值属性被截断。

The Graph Markup Language (GraphML) [13] is a file format to store graphs as XML. GraphML has two sections. The first section is the definition of the property names and datatypes of edges and nodes. Before defining the properties of a node, a special property labelV can be used to store node labels. Then, all the node property names are defined. Similarly, the property labelE can be defined for edge labels followed for all edge property names. In the second section, each node is defined within a <node> tag containing its labels and property values; and then each edge is similarly described within an <edge> tag. Properties are defined with <data> tags specifying the name in the key attribute. Multiple <data> tags with the same key value are not permitted for a node or edge in order to support multi-valued properties. In Figure 2, we present a GraphML file that serializes the data of the property graph shown in Figure 1, where multi-label and multi-valued properties are truncated.

图 2.

GraphML 格式的示例。

Example of the GraphML format.

显示全部

Show All

B. YARS-PG

B. YARS-PG

YARS-PG 是一种旨在支持属性图发布和交换的数据格式。YARS-PG 有两个版本，分别在[14]和[15]中介绍。在本文中，我们考虑第一个版本，因为它的语法比第二个版本中定义的语法更简单。

YARS-PG is a data format designed to support the publication and exchange of property graphs. There are two versions of YARS-PG which are presented in [14] and [15] respectively. In this article we consider the first version because its syntax is simpler than the one defined in the second version.

在 YARS-PG 文件中，必须先定义节点声明，然后再定义边声明。节点声明以节点 ID 开头，后跟方括号 ([]) 包含该节点的标签列表，用冒号 (：)，并以花括号 ({}) 结尾，其中包含表示节点的属性名称和值的键/值对。边声明以源节点的 ID 开头，括在括号中。后面跟着一个连字符 (-）。方括号内放置一个边的标签，后跟一个空格，然后是花括号内的属性名称和值列表（类似于节点的情况）。之后，附加一个 ASCII 箭头（->）。最后，在括号中添加目标节点的 ID。

In a YARS-PG file, declarations for nodes must be defined first, and then followed by declarations for edges. A node declaration begins with the node ID, followed by square brackets ([]) that enclose a list of labels for that node separated by colons (:), and ends with curly braces ({}) that contain key/value pairs representing the property names and values of the node. An edge declaration begins with the ID of the source node, enclosed in parentheses. This is followed by a hyphen (-). Within square brackets, one label for the edge is placed, followed by a space, and then the list of property names and values enclosed in curly braces (similar to the case of nodes). Afterwards, an ASCII arrow is appended (->). Finally, the ID of the target node is added in parentheses.

在图 3中，我们展示了图 1中所示属性图的 YARS-PG 声明，其中多值属性被截断，因为 YARS-PG 未明确提供对它们的支持（例如，通过定义数组）。请注意，YARS-PG 仅支持每条边一个标签。

In Figure 3, we present the YARS-PG declarations for the property graph shown in Figure 1, where multi-valued properties are truncated, as YARS-PG does not explicitly provide support for them (e.g., by defining arrays). Note that YARS-PG supports only one label per edge.

图 3.

YARS-PG 格式的示例。

Example of the YARS-PG format.

显示全部

Show All

C.PG 格式

C. PG Format

PG 格式[16]是一种类似于 YARS-PG 的交换格式，但语法更简单，并且允许通过重复键来实现多值属性。每个节点和每条边都在自己的行上，ID、标签和属性/值对的字段用空格分隔。在图 4中，我们展示了图 1中显示的属性图的序列化，其中可以注意到边标识符丢失了。

PG Format [16] is an exchange format similar to YARS-PG, but with a simpler syntax and allowing multi-valued properties by repeating the key. Each node and each edge are on their own line, with space separated fields for IDs, labels and property/value pairs. In Figure 4 we present the serialization of the property graph shown in Figure 1, where it can be noted that edge identifiers are lost.

图 4.

PG 格式的示例。

Example of the PG Format.

显示全部

Show All

D.JSON-Neo4j

D. JSON - Neo4j

Javascript 对象表示法 (JSON) 也可用于序列化属性图。Neo4j 定义了自己的导入/导出 JSON 格式，其中每个节点和边都序列化为一个对象，以类型属性。在每个对象中，标签、属性名称和值都以通常的 JSON 方式序列化，图 5中给出了一个示例，其中展示了一个用于 Neo4j 的 JSON，它序列化了图 1的属性图。

The Javascript Object Notation (JSON) can also be used to serialize property graphs. Neo4j defines their own import/export JSON format, where each node and edge is serialized as an object distinguished by the type property. In each object, labels, property names, and values are serialized in the usual JSON way, for which an example can be found in Figure 5 presenting a JSON for Neo4j that serializes the property graph of Figure 1.

图 5.

JSON-Neo4j 格式的示例。

Example of the JSON-Neo4j format.

显示全部

Show All

E. GraphSON-TinkerPop3

E. GraphSON - TinkerPop3

GraphSON - TinkerPop 3 (TP3) 是一种受 JSON 启发的序列化属性图的数据格式，旨在易于在分布式系统中拆分和加载。在 GraphSON 文件中，每个节点都被序列化为一个 JSON 对象，该对象具有节点的 id 和标签，以及三个嵌套对象。第一个嵌套对象包含从节点出去的所有边：它们的 id、标签和属性。第二个嵌套对象包含进入节点的所有边。第三个嵌套对象包含节点的属性名称和值。在图 6中，我们展示了一个 GraphSON 文件，它表示图 1中所示的属性图，其中多标签被截断，因为这些标签不受明确支持。

GraphSON - TinkerPop 3 (TP3) is a data format for serializing property graphs inspired in JSON and aiming to be easy to split and load in distributed systems. In a GraphSON file, each node is serialized as a JSON object that has the id and labels of the node, along with three nested objects. The first nested object contains all edges going out of the node: their ids, labels and properties. The second nested object contains all edges going into the node. The third nested object contains the property names and values of the node. In Figure 6, we present a GraphSON file that represents the property graph shown in Figure 1, where multi-labels are truncated, as these are not explicitly supported.

图 6.

GraphSON-TP3 格式的示例。

Example of the GraphSON-TP3 format.

显示全部

Show All

F. 数据格式分析

F. Analysis of Data Formats

表 1显示了上述数据格式的比较。我们考虑了属性图中可能出现的不同特性，并说明它们是否明确受支持。显然，没有一种格式支持所有列出的特性，其中 JSON-Neo4j 和 PG 格式是最完整的。可以说，有些格式可以这样使用，即它们支持一些缺失的特性，但我们会报告每种数据格式的论文或文档中所述的明确支持的特性。

Table 1 shows a comparison of the data formats described above. We considered different features that can appear in property graphs and state if they are explicitly supported or not. It is evident that none of the formats supports all the listed features, with JSON-Neo4j and PG Format being the most complete. It can be argued that some of the formats can be used in such a way that they support some of the missing features, but we report the explicitly supported features as stated in the papers or documentation of each data format.

表 1不同数据格式支持的属性图特征

A. 换算方法

A. Conversion Method

在本节中，我们将介绍一种将存储为一组 CSV 文件的属性图转换为单个 PGDF 文件的方法。将属性图导出为 CSV 时，通常每种类型的节点或边都有一个 CSV 文件。这些“类型”通常对应于所述边和节点的标签。因此，CSV 到 PGDF 转换方法的输入是一组 CSV 文件，其中每个节点类型和边类型都是一个单独的文件。

In this section we describe a method for converting a property graphs stored as a set of CSV files to a single PGDF file. When a property graph is exported to CSV, it is often the case that there is a CSV file for each type of node or edge. These “types” usually correspond to the labels of said edges and nodes. Therefore, the input of the CSV-to-PGDF conversion method is a set of CSV files where each node type and edge type is a separate file.

为了使输入的 CSV 文件有意义，我们需要创建一个配置 JSON 文件，其中给出了每个单独文件的路径，以便用户可以指定其中哪些是节点，哪些是边，分隔符是什么以及文件是否有标题。此外，用户可以指定列的名称，因为它们是 PGDF 所必需的。

To give some meaning to the input CSV files, we require the creation of a configuration JSON file in which the paths to each individual file are given, such that the user can specify which of these are meant to be nodes and which are meant to be edges, what are the delimiter characters and if the file has a header or not. Furthermore, the user can specify the names of the columns, as they are required by PGDF.

在图 9中，我们展示了 JSON 配置文件的模板。在图中我们可以看到两个根级对象：节点和边缘. 在节点对象，我们列出了代表节点的 CSV 文件，对于每个文件，用户必须分配以下属性：

In Figure 9, we show a template of the JSON configuration file. In the figure we can see two root-level objects: nodes and edges. In the nodes object, we list the CSV files that represent nodes where, for each file, the user must assign the following properties:

1. ID，为 CSV 文件提供标识符，以便稍后引用它；

1. id, to give an identifier to the CSV file, required to refer to it later;

2. 文件，指示相应 CSV 文件的位置路径（在硬盘上）；

2. file, to indicate the location path (on hard disk) to the corresponding CSV file;

3. 分隔符，表示 CSV 文件中字段的分隔字符；

3. delimiter, to indicate the character separating the fields in the CSV file;

4. 标题，一个布尔值，指示 CSV 文件是否有标题；

4. header, a boolean value to indicate if the CSV file has a header or not;

5. 标签，从 CSV 文件中提取的分配给节点的标签列表；

5. labels, a list of labels to assign to the nodes extracted from the CSV file;

6. 特性，强制 PGDF 属性列表（例如，@ID) 和属性名称，按照它们在 CSV 文件列中出现的顺序排列。

6. properties, the list of mandatory PGDF attributes (e.g., @id) and property names in the order these appear in the columns of the CSV files.

1. 文件，指示相应 CSV 文件的位置路径；

1. file, to indicate the location path to the corresponding CSV file;

2. 分隔符，表示 CSV 文件中字段的分隔字符；

2. delimiter, to indicate the character separating the fields in the CSV file;

3. 标题，一个布尔值，指示 CSV 文件是否有标题；

3. header, a boolean value to indicate if the CSV file has a header or not;

4. 标签，分配给从 CSV 文件中提取的边的标签；

4. label, the label to assign to the edges extracted from the CSV file;

5. 目录， 这是真的或者错误的取决于边缘是否有向；

5. dir, it is true or false depending on whether the edge is directed or not;

6. 来源， 这IDCSV 文件中包含与边 255 关联的源节点的 ID；

6. source, the id of the CSV file that contains the ids of the source nodes associated with the edges255 in the CSV file;

7. 目标， 这IDCSV 文件中包含与该 CSV 文件中边关联的目标节点的 ID；

7. target, the id of the CSV file that contains the ids of the target nodes associated with the edges contained in the CSV file;

8. 特性，强制 PGDF 属性列表（例如，@在和@出去) 和属性名称，其顺序与 CSV 列中的显示顺序一致。@ID属性对于边来说是可选的。

8. properties, the list of mandatory PGDF attributes (e.g., @in and @out) and property names in the order they appear in the columns of the CSV. The @id property is optional for edges.

图 9.

将 CSV 文件转换为 PGDF 所需的 JSON 配置文件模板。

Template of the JSON configuration file required to convert CSV files to PGDF.

显示全部

Show All

图 9中的模板用于将三个 CSV 文件转换为一个 PGDF 文件，其中两个 CSV 文件（节点1.csv和节点2.csv）存储节点和第三个文件（边缘.csv) 存储边缘。

The template in Figure 9 is used to convert three CSV files to one PGDF file, where two of the CSV files (nodes1.csv and nodes2.csv) store the nodes and the third file (edges.csv) stores the edges.

然后，为了将 CSV 文件集转换为 PGDF，我们遵循算法 1，因为每个 CSV 文件仅包含一种类型的节点或边模式。首先，将每个包含节点的 CSV 文件序列化为 PGDF。使用 JSON 配置文件定义的各自 JSON 对象中的信息创建每个节点模式的模式。然后，根据 CSV 文件中每行的信息格式化每个 PGDF 数据行。我们对边重复类似的过程。

Then, to convert the set of CSV files to PGDF, we follow Algorithm 1, as each CSV file contains only one type of node or edge schema. First, each CSV file containing nodes is serialized to PGDF. The schema of each node schema is created using the information in its respective JSON object as defined by the JSON configuration file. Then, each PGDF data line is formatted according to the information of each line in the CSV file. We repeat a similar process for edges.

B. 转换工具

B. Conversion Tool

上面描述的 CSV 到 PGDF 转换方法是用 Java 实现的，我们将其封装为 Java 存档 (JAR) 文件，作为我们工具的分发格式，称为CSV2PGDF。该工具可在以下存储库公开获取：https://github.com/dbgutalca/pgdf。

The CSV-to-PGDF conversion method described above was in Java, and we encapsulated it as a Java Archive (JAR) file, which serves as the distribution format for our tool called CSV2PGDF. The tool is publicly available at the following repository: https://github.com/dbgutalca/pgdf.

这CSV2PGDF可以使用以下形式的指令来执行该工具（例如在 Linux 命令行中）：

The CSV2PGDF tool can be executed (e.g. in a Linux command line) by using an instruction of the form:

java -jar CSVConverter pgdf /路径/到/JSON

java -jar CSVConverter pgdf /path/to/JSON

/路径/到/输出/文件夹

/path/to/output/folder

这CSV2PGDF工具需要两个参数：JSON 配置文件的路径，以及用户希望存储生成的 PGDF 文件的路径。请注意，各个 CSV 文件的路径是从 JSON 配置文件中读取的。

The CSV2PGDF tool requires two parameters: the path to the JSON configuration file, and the path to where the user wishes to store the resulting PGDF file. Notice that the paths to the individual CSV files are read from the JSON configuration file.

C. 用例

C. Use-Case

现在，我们给出一个用例示例，说明如何将图形数据从其原始 CSV 格式转换为 PGDF。为此，我们使用 LDBC 社交网络基准[7]的数据生成器，该生成器可以使用各种比例因子创建合成属性图。生成的图有八种类型的节点：评论，论坛，组织，人，地方，邮政，标签， 和标签类。这些节点通过 23 种不同的边连接，这些边连接特定类型的节点。例如，类型为有主持人连接论坛节点人节点。可以在[7]中找到所有类型的节点，边和属性名称的完整描述。

We now present a use-case example that illustrates how graph data can be converted from its original CSV format to PGDF. To do this, we use the data generator of the LDBC Social Network Benchmark [7], which enables the creation of synthetic property graphs using various scale factors. A generated graph has eight types of nodes: Comment, Forum, Organization, Person, Place, Post, Tag, and TagClass. These nodes are connected through 23 different kinds of edges, which connect nodes of specific types. For example, the edges of type hasModerator connect Forum nodes with Person nodes. A full description of all types of nodes, edges and property names can be found in [7].

SNB 数据生成器输出一组 CSV 文件。每个 CSV 文件都包含与节点类型或边类型相关的数据。要使用CSV2PGDF转换工具，我们需要定义 JSON 配置文件，我们在图 10中展示了该文件的摘录。在该图中，我们仅显示了以下类型的节点人，评论， 和邮政，边缘类型喜欢連接人和邮政和人和评论节点和边类型有创作者連接评论和人节点。转换 LDBC-SNB 生成器生成的所有 CSV 文件所需的完整 JSON 配置文件可在以下 URL 中找到：https://github.com/dbgutalca/pgdf/blob/main/config0.1.json。

The SNB data generator outputs a collection of CSV files. Each CSV file includes data pertaining to either a node type or an edge type. To convert the multiple CSV files to PGDF using CSV2PGDF conversion tool, we need to define the JSON configuration file, of which we present an extract in Figure 10. In said figure, we only show nodes of types Person, Comment, and Post, with edges of type likes connecting Person with Post and Person with Comment nodes, and edges of type hasCreator connecting Comment and Person nodes. The complete JSON configuration file required to convert all the CSV files produced by the LDBC-SNB generator can be found in the following URL: https://github.com/dbgutalca/pgdf/blob/main/config0.1.json.

图 10.

提取 JSON 配置文件，从使用 LDBC 社交网络基准的数据生成器生成的数据中生成 PGDF 文件。

Extract of the JSON configuration file to produce PGDF files from data produced with the data generator of the LDBC Social Network Benchmark.

显示全部

Show All

使用CSV2PGDF转换工具和前面提到的 JSON 配置文件，我们可以将一组 CSV 文件转换为单个 PGDF 文件。对于这个实验，我们考虑了几种比例因子的 LDBC-SNB 文件。在表 3中，我们比较了不同比例因子下的所有 31 个 LDBC-SNB CSV 文件的大小总和与生成的 PGDF 文件1。可以看出，PGDF 文件平均比 CSV 文件大约大 27.8%，这主要是由于文件每一行中节点和边的标签重复。在第七部分中，我们表明 PGDF 仍然比其他属性图数据格式更方便，因为 PGDF 比其他格式更容易生成、更紧凑。

Using the CSV2PGDF conversion tool, and the aforementioned JSON configuration file, we can convert the set of CSV files into a single PGDF file. For this experiment, we consider the LDBC-SNB files for several scale factors. In Table 3, we present a comparison between the sum of the sizes of all 31 CSV files of the LDBC-SNB at different scale factors and the resulting PGDF file.1 It can be seen that PGDF files are in average ~27.8% larger than the CSV files, which is mostly due to the repetition of the labels of the nodes and edges in each line of the file. In Section VII, we show that PGDF is still more convenient than other data formats for property graphs, as PGDF is easier to generate and more compact than the alternatives.

表 3本文使用的 LDBC-SNB 属性图的信息

A.基于主内存的转换

A. Main Memory-Based Conversion

此方法的输入是一组内存对象，这些对象对属性图的节点和边及其标签和属性进行建模。然后，此表示将以目标数据格式进行序列化。此方法最适合内存中可以容纳的较小图。

The input of this method is a set of in-memory objects that model the nodes and edges of the property graph, along with their labels and properties. This representation is then serialized in the destination data format. This method is most suitable for smaller graphs that can fit in memory.

属性图可以用两种方式序列化。节省空间的方式需要根据模式对节点和边进行分区，然后每个组只能在一个模式行下序列化。但是，分区在实践中可能很昂贵，因此可以考虑第二种转换方法。我们访问每个节点和边一次，如果当前节点或边具有与先前处理的节点或边相同的模式，则序列化该节点或边。如果当前节点或边具有不同的模式，则引入新的模式声明，然后序列化节点或边。我们将第一种方法称为 PGDF-srt（已排序），将第二种方法称为 PGDF-unsrt（未排序）。

A property graph can be serialized in two ways. The space-efficient way requires to partition the nodes and edges according to the schema, and then each group can be serialized under only one schema line. However, partitioning can be expensive in practice, thus a second conversion method can be considered. We visit each node and edge once, if the current node or edge has the same schema as the previously processed one, then the node or edge is serialized. If the current node or edge has a different schema, then a new schema declaration is introduced and then the node or edge is serialized. We call the first method PGDF-srt (sorted), and the second PGDF-unsrt (unsorted).

YARS-PG 的序列化非常直接，因为每个节点和每条边及其标签和属性都被序列化为一行。为了生成符合 Neo4j 的 JSON，我们遵循为 YARS-PG 定义的流程。为此，我们为每个节点和边添加一个 JSON 对象。对于节点，我们使用属性“类型”：“节点”在物体中；对于边缘，我们使用“类型”：“关系”，并为边的源节点和目标节点 id 添加嵌套的 JSON 对象。

Serialization to YARS-PG is very direct, as each node and each edge, along with their labels and properties, are serialized as a line. To produce Neo4j compliant JSON, we follow a process as defined for YARS-PG. For this, we add a JSON object for each node and edge. For nodes, we use the property “type”: “node” in the object; and for edges, we use “type”: “relationship”, and add nested JSON objects for the source and target node ids of the edge.

对于 GraphML，我们首先需要图中的所有属性名称。因此，我们遍历所有节点和边，并添加一个钥匙GraphML 文件中每个唯一属性名称的标签。然后，对于每个节点（分别为边），我们完成一个节点（分别边缘) 标签中包含该行的信息。

For GraphML, we first need all the property names in the graph. So we iterate through all nodes and edges, and add a key tag in the GraphML file for each unique property name. Then, for each node (resp. edge), we complete a node (resp. edge) tag including the information in the line.

为了在 GraphSON 中序列化图形，我们需要跟踪每个节点的所有传入和传出边。这样，我们就可以根据第 III-E 节中的定义将每个节点序列化为 GraphSON 对象。这表明创建 GraphSON 文件的过程是昂贵的。

To serialize the graph in GraphSON, we need to keep track of all in-going and out-going edges of each node. In this way, we can serialize each node as a GraphSON object, according to the definition in Section III-E. This suggests that the process of creating a GraphSON file is expensive.

B. 磁盘转换方法

B. Disk Conversion Method

我们还定义了一个过程，用于将存储在多个 CSV 文件中的属性图转换为其他数据格式。上面介绍了将 CSV 转换为 PGDF 的过程，此时需要 JSON 配置文件（参见图 9）来定义一些转换参数。

We also define a procedure to convert a property graph stored in several CSV files to the other data formats. The process to convert CSV to PGDF was presented above, when a JSON configuration file (see Figure 9) is required to define some conversion parameters.

要将 CSV 转换为 YARS-PG，我们首先浏览包含节点的所有文件。对于每个文件，我们浏览每一行，并使用 JSON 配置，从 JSON 配置和当前 CSV 行中提取 ID、标签、属性名称和属性值，从而制作每个节点的序列化。对于边，我们遵循相同的过程。

To convert CSV to YARS-PG, we first go through all the files containing nodes. For each file, we go through each line, and using the JSON configuration, we craft the serialization of each node extracting the id, labels and property names and property values from both the JSON configuration and the current CSV line. For edges, we follow the same process.

可以按照类似的方法生成 JSON，其中考虑到 JSON 配置文件，为每个节点/边 CSV 文件中的每一行创建一个节点或关系对象。

A similar method can be followed to generate JSON, where a node or relationship object is created for each line in each node/edge CSV file, considering the JSON configuration file.

为了将 CSV 文件序列化为 GraphML，我们首先从 JSON 配置文件中获取所有不同的节点和边属性名称，以创建前言<键>标签。然后，我们创建<节点>和<边缘>对象类似于我们对 PGDF、JSON 和 YARS-PG 所做的那样。

To serialize the CSV files into GraphML, we first get all the distinct node and edge property names from the JSON configuration file to create the preamble <key> tags. Then, we create the <node> and <edge> objects similarly as we do for PGDF, JSON and YARS-PG.

最后，将 CSV 转换为 GraphSON 并不像转换为其他数据格式那样直接。对于每个包含节点的 CSV 文件的每一行，必须读取所有包含边的文件以获取节点的传入和传出边。我们利用IDJSON 配置文件中的属性，因此，我们只读取声明为来源或者目标这ID正在处理的节点。

Finally, converting CSV to GraphSON is less direct than to the other data formats. For each line of each CSV file containing nodes, all files containing edges must be read to get the node’s in-going and out-going edges. We make use of the id attribute in the JSON configuration file, thus, we read only the edge files that declare as source or target the id of the node being processed.

可以在以下位置完成从 CSV 到 PGDF、YARS-PG、JSON 和 GraphML 的转换欧( | V| + | E| ) 时间，而 GraphSON 需要欧( | V| ⋅ | E| ) 时间。

Conversion from CSV to PGDF, YARS-PG, JSON, and GraphML can be done in O(|V|+|E|) time, whereas to GraphSON requires O(|V|⋅|E|) time.

C. 实施

C. Implementation

上面描述的转换方法以 Java 应用程序的形式实现，并以 JAR 文件的形式分发。代码可以在本文的 GitHub 存储库中找到。要执行该工具，我们将使用以下形式的指令：

The conversion methods described above were implemented as a Java application and distribute as a JAR file. The code can be found in the GitHub repository of the paper. To execute the tool, we shall use a instruction of the form:

java -jar CSVConverter [内存]

java -jar CSVConverter [memory]

graphml|json|graphson|yarspg

graphml| json|graphson|yarspg

/路径/到/JSON/配置

/path/to/JSON/configuration

/路径/到/目标/文件夹

/path/to/destination/folder

用户必须包含所需的输出格式（GraphML、JSON-Neo4j、GraphSON 或 YARS-PG）、JSON 配置文件的路径以及所需输出文件的路径。可选参数 --memory 允许激活-记忆转换。

where the user must include the desired output format (GraphML, JSON-Neo4j, GraphSON or YARS-PG), the path to the JSON configuration file, and the path to the desired output file. The optional parameter --memory allows to activate the in -memory conversion.

A. 文件大小比较

A. Comparison of File Size

首先，我们比较了 PGDF、YARS-PG、JSON 和 GraphML 生成的文件大小。我们没有报告 GraphSON 序列化的结果，因为生成它太耗时了。事实上，从 G1 生成 GraphSON 的尝试执行了三个小时，但仍然没有完成。

First, we compare the sizes of the files produced for PGDF, YARS-PG, JSON and GraphML. We do not report results for GraphSON serialization, as it is excessively time-consuming to produce. Indeed, an attempt to generate GraphSON from G1 was executed for three hours and still did not finish.

表 4显示了所比较图形格式所生成的文件的大小。此外，我们还在图 11中显示的图表中描述了这些结果，其中 Y 轴为对数刻度。在表 4和图 11中，我们都可以看到 PGDF 始终比其他数据格式占用更少的磁盘空间。YARS-PG 的表现略差于 PGDF，因为这种格式为边引入了 ASCII 艺术字符，以及属性值的类似 JSON 的表示，所有这些都使用了更多字符，并且在每一行中重复属性名称。GraphML 和 JSON 的表现都差得多，因为这些格式需要几个 PGDF 和 YARS-PG 均未使用的分隔符和引号字符。

The sizes of the files generated for the compared graph formats are presented in Table 4. Additionally, we have also depicted these results in the chart displayed in Figure 11, where the Y-axis is in log scale. In both, Table 4 and Figure 11, we can see that PGDF always uses less disk space than the other data formats. YARS-PG performs slightly worse than PGDF, as this format introduces ASCII art characters for edges, as well as a JSON-like representation of the property values, all of which use more characters, and repeat property names in each line. Both GraphML and JSON perform much worse, as these formats require several delimiter and quotation characters which are not used by PGDF nor YARS-PG.

表 4使用不同比例因子生成并以不同数据格式（PGDF、YARS-PG、GraphML 和 JSON-Neo4j）序列化的 LDBC-SNB 属性图的文件大小

图 11.

每个图表每个格式的文件的大小。

The sizes of the files per graph per format.

显示全部

Show All

B. 转换时间比较

B. Comparison of Conversion Time

接下来，我们评估将以不同方式存储的属性图转换为每种数据格式所需的时间：PGDF、YARS-PG、JSON-Neo4j 和 GraphML。我们特别关注上面定义的基于内存和基于磁盘的转换方法。我们将这些转换方法应用于表 3中显示的属性图 G1–6 。对于每种转换方法、数据格式、图和机器，我们都报告了执行时间。转换是使用我们的 CSVConverter 工具执行的。

Next, we evaluate the time required to convert property graphs stored in different manners to each data format: PGDF, YARS-PG, JSON-Neo4j, and GraphML. We particularly focus on the memory-based and disk-based conversion methods defined above. We apply these conversion methods to the property graphs G1–6, presented in Table 3. For each conversion method, data format, graph, and machine we report the execution time. Conversion was performed using our CSVConverter tool.

对于基于内存的转换，我们首先读取 G1–6 的 CSV 文件，并使用 Java 对象将其加载到内存中。然后，根据每种格式的规则创建内存中图的序列化。在表 5中，我们列出了每台机器、图形和数据格式的执行时间。图 12a和12b也分别针对机器 M1 和 M2 显示了这些时间（Y 轴为对数刻度）。考虑到 M1，我们可以看到在 Java 耗尽堆空间之前，只有 G1 和 G2 可以转换。使用 M2，我们能够转换 G3。可以看出，PGDF 的生成速度比其他方法更快，大约是生成 YARS-PG 所需时间的 70%。请注意，我们对此转换使用了 PGDF-unsrt 策略。就文件大小而言，使用 PGDF-unsrt 生成的文件比使用 YARS-PG 生成的文件小，尽管 PGDF-unsrt 生成了重复的模式声明。使用 PGDF-unsrt 获得的文件大小为 G1 89 MB、G2 270 MB 和 G3 1019 MB。

For the memory-based conversion, we first read the CSV files of G1–6 and load them to memory using Java objects. Then, serializations of the in-memory graph are created according to the rules of each format. In Table 5, we present the execution time for each machine, graph and data format. These times are also presented in Figures 12a and 12b for machines M1 and M2, respectively (the Y-axis are in log scale). Considering M1, we can see that only G1 and G2 could be converted before Java runs out of heap space. With M2, we were able to convert G3. It can be seen that PGDF is faster to produce than the alternatives, taking around 70% of the time required to produce YARS-PG. Note that we used the PGDF-unsrt strategy for this conversion. In terms of file size, files produced with PGDF-unsrt are smaller than the ones produced with YARS-PG, despite PGDF-unsrt producing repeated schema declarations. The file sizes obtained with PGDF-unsrt are 89 MB for G1, 270 MB for G2, and 1019 MB for G3.

表 5基于内存的转换的执行时间

图 12.

基于内存的转换的执行时间。

The execution times for the memory-based conversion.

显示全部

Show All

在基于磁盘的转换情况下，我们直接将 CSV 文件转换为所考虑的数据格式。表 6显示了转换时间（以秒为单位）。图 13a和13b也显示了这些时间，其中 Y 轴为对数刻度。可以注意到，PGDF 总是能更快地生成输出。这是因为 CSV 文件的字段在分离后不需要太多的后处理即可重写为 PGDF。相比之下，YARS-PG、GraphML 和 JSON 需要将每个 CSV 行与 JSON 配置文件中声明的字段组合在一起，而 PGDF 则不需要这样做。此外，GraphML 需要额外的时间，因为它需要创建钥匙在文件开头使用图中存在的不同属性名称添加标签。用于实验的两台机器的执行时间没有显著差异，可能是因为转换中最耗时的部分是 I/O 操作。

In the disk-based conversion case, we directly convert the CSV files to the considered data formats. The resulting conversion times (in seconds) are shown in Table 6. These times are also presented in Figures 13a and 13b, where the Y-axis is in log scale. It can be noticed that PGDF is always faster to produce the output. This is because the fields of the CSV file, after being separated, do not require much post-processing to be re-written to PGDF. In contrast, YARS-PG, GraphML and JSON require the combination of each CSV line with the fields declared in the JSON configuration file, which is not needed for PGDF. Furthermore, GraphML takes extra time, as it needs to create the key tags at the start of the file with the different property names present in the graph. There is not a significant difference in execution time between the two machines used for the experiment, probably because the most time consuming part of the conversion are I/O operations.

表 6基于磁盘的转换的执行时间

图 13.

基于磁盘的转换的执行时间。

The execution times for the disk-based conversion.

显示全部

Show All

写作过程中生成式人工智能和人工智能辅助技术的宣言

Declaration of Generative AI and AI-Assisted Technologies in the Writing Process

在准备本作品期间，作者使用了 AI-PRO Grammar AI 来改善语言和可读性。使用此工具/服务后，作者根据需要审查和编辑了内容，并对出版物的内容负全部责任。

During the preparation of this work the author(s) used AI-PRO Grammar AI in order to improve language and readability. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the content of the publication.